FYI we had something similar, but not over websocket: https://github.com/Geod24/agora-server/blob/v0.x.x/source/agora/network/RPC.d
Can a server be registered with both ?

FYI we had something similar, but not over websocket: https://github.com/Geod24/agora-server/blob/v0.x.x/source/agora/network/RPC.d

Didn't know about that, also looks interesting, especially since that can probably be better tuned for performance for cases where that is important.

Can a server be registered with both ?

To avoid me talking nonsense, can you clarify what you mean with "both"? ;-)

Implemented vibe.web.auth support.

To avoid me talking nonsense, can you clarify what you mean with "both"? ;-)

Our need was to expose an API. Starting with a REST API was super easy, because you just write an interface, the business-side implementation in the class, and voila. You have tons of tools available to deal with REST APIs, even from one's browser.
When we put things into production, we needed more performance, so we went with our TCP-based RPC approach. If I was to do it today, I'd look into HTTP/3. But we also wanted to be able to interact with the server in a more developer friendly way. So we ended up registering the business logic class on 0.0.0.0 with the RPC listener, and on 127.0.0.1 for the REST API, so we could still issue requests to it. That was extremely useful for dev speed.

Okay, yeah, that makes sense. I've also made sure to make most use cases work for REST and for the new module using the same interface definition. HTTP/2 and HTTP/3 would indeed be logical candidates to support as a replacement for or as an addition to WebSockets, but that of course is a big project just to get the protocol itself supported. I hope to get the HTTP/2 work integrated this year, which already shares a lot with HTTP/3. Hopefully the existing work on QUIC will then make it possible to get an HTTP/3 implementation relatively easily.